Amazon Auroraのbinlogを有効にしAmazon MySQLにレプリケートしてみる
はじめに
Aurora は本家 MySQL とはことなり binlog によらないレプリケーションを採用しており、プレビューの当初は binlog を有効にできませんでした。いつからか Aurora が binlog 対応したようなので、この機能をつかって Amazon Aurora から Amazon MySQL にレプリケートしてみたいと思います。
全体の流れ
同じ VPC 内に
- RDS for Aurora
- RDS for MySQL
を起動します。
その後、Aurora の binlog パラメーターを有効にし、この binlog をもとに MySQL にレプリケートさせます。
レプリケート方法は次のドキュメントと同等の手順をとります。
Amazon RDS の外部で実行される MySQL インスタンスとのレプリケーション
RDS インスタンスの起動
RDS for Aurora の起動
主役となる Aurora インスタンスです。
まだ東京リージョンにはやってきていません。以下のリージョンでご利用ください。
- US East (N. Virginia)
- US West (Oregon)
- EU (Ireland)
RDS for MySQL の起動
将来的に Aurora のリードレプリカとなる MySQL インスタンスです。 画面をポチポチしながら MySQL 5.6 を起動します。
注意点としては、バックアップが有効になっていないと、リードレプリカになれません。
維持費を削ろうと "Backup Retention Period : 0 days" で作成すると、リードレプリカ化しても、以下の様な警告メッセージが表示され、レプリケーションが有効になりません。
Read replica creation requires backups to be enabled. Use the modify wizard to enable backups for supported engine versions.
テーブルにテストデータを投入
Aurora インスタンスにテストデータを投入します。
mysql> CREATE TABLE characters(
-> id Integer NOT NULL AUTO_INCREMENT,
-> name varchar(255) NOT NULL,
-> PRIMARY KEY (id)
-> );
Query OK, 0 rows affected (0.22 sec)
mysql> INSERT INTO characters(name) VALUES
-> ('Max Rockatansky'),
-> ('Imperator Furiosa'),
-> ('Nux');
Query OK, 3 rows affected (0.23 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from characters;
+----+-------------------+
| id | name |
+----+-------------------+
| 1 | Max Rockatansky |
| 2 | Imperator Furiosa |
| 3 | Nux |
+----+-------------------+
3 rows in set (0.25 sec)
Aurora の binlog を有効にする
MySQL 本来のレプリケーション情報を確認してみる
mysql> show variables like 'binlog_format'; +---------------+-----------+ | Variable_name | Value | +---------------+-----------+ | binlog_format | STATEMENT | +---------------+-----------+ 1 row in set (0.27 sec) mysql> show binary logs; ERROR 1381 (HY000): You are not using binary logging mysql> call mysql.rds_show_configuration; +------------------------+-------+------------------------------------------------------------------------------------------------------+ | name | value | description | +------------------------+-------+------------------------------------------------------------------------------------------------------+ | binlog retention hours | NULL | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. | +------------------------+-------+------------------------------------------------------------------------------------------------------+ 1 row in set (0.22 sec) Query OK, 0 rows affected (0.22 sec) mysql> show master status; Empty set (0.25 sec) mysql> show global variables like 'server_id'; +---------------+------------+ | Variable_name | Value | +---------------+------------+ | server_id | 1475017092 | +---------------+------------+ 1 row in set (0.19 sec)
Parameter Groups の変更
Aurora には
- DB インスタンスを制御する DB Parameter Group
- クラスターに関連する DB Cluster Parameter Group
の2種類の Parameter Group が存在します。
binlong は後者の DB Cluster Parameter Group の binlog_format で管理します。
まず Parameter Group(DB Cluster Parameter Group) を新規作成
binlog_format が OFF になっているので MIXED(や STATEMENT) にします。
Parameter Group の変更
Aurora インスタンスの Modify から Parameter Group を先ほど作成した binlog を有効したものに変更します。
Apply Immediately をチェックすれば、すぐに反映されることを期待したのですが Configuration Details の "DB Cluster Parameter Group" を確認すると DB Cluster Parameter GroupDatabase parameter group to associate with this DB instance. aurora-binlog-enabled ( pending-reboot ) というメッセージが表示されていたため、手動でリブートをかけました。
新しい Parameter Groups を確認
reboot 後のパラメーターを確認しましょう。
binlog_format が MIXED となっており binlog が生成されているのが確認できます。
mysql> SHOW VARIABLES LIKE 'binlog_format'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | MIXED | +---------------+-------+ 1 row in set (0.20 sec) mysql> show binary logs; +----------------------------+-----------+ | Log_name | File_size | +----------------------------+-----------+ | mysql-bin-changelog.000001 | 7712 | +----------------------------+-----------+ 1 row in set (0.13 sec) mysql> show master status; +----------------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------------------------+----------+--------------+------------------+-------------------+ | mysql-bin-changelog.000001 | 12384 | | | | +----------------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.15 sec)
以下のコマンドを叩くと、binlog ファイルをローカル環境にコピー出来ます。
$ mysqlbinlog --read-from-remote-server -h HOSTNAME -u USERNAME -p mysql-bin-changelog.000001 --result-file=mysql-bin-changelog.000001
MySQL をリードレプリカ化する
最後にこの binlog をもとに MySQL インスタンスを Aurora のリードレプリカ化します。
aurora でレプリケーションユーザーを作成
aurora サーバでレプリケーションユーザー(repl_user)を作成します。 レプリカからはこのユーザーでマスターに接続します。
CREATE USER 'repl_user'@'%' IDENTIFIED BY '<PASSWORD>'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY '<PASSWORD>';
Aurora のデータをダンプする
DBダンプ前に binlog の位置を控えておきます。
mysql> show master status; +----------------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------------------------+----------+--------------+------------------+-------------------+ | mysql-bin-changelog.000020 | 123280 | | | | +----------------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.20 sec)
以下のコマンドでDBダンプします。
$ mysqldump -u USERNAME -p -h Aurora_HOSTNAME --databases DBNAME --single-transaction --order-by-primary -r backup.sql
本当は --master-data オプションをつけてダンプ時の binlog の位置を把握したいのですが、RDS でこのプションを有効にすると
"mysqldump: Couldn't execute 'FLUSH TABLES WITH READ LOCK': Access denied for user ..." というエラーが発生するようです。(回避策をご存知のかたは教えて下さい)
MySQL にダンプデータを取り込む
以下のコマンドで MySQL にデータを取り込みます。
$ mysql -h MySQL_HOSTNAME -u USERNAME -p DBNAME < backup.sql
MySQL にデータが取り込めていることを確認します。
mysql> select * from characters; +----+-------------------+ | id | name | +----+-------------------+ | 1 | Max Rockatansky | | 2 | Imperator Furiosa | | 3 | Nux | +----+-------------------+ 3 rows in set (0.17 sec)
MySQL でスレーブ設定を行う
MySQL 側で
- マスター(Aurora)サーバ
- レプリケーション用ユーザ
- binlog の位置
の情報とともに、レプリケーション設定を行います。
mysql> CALL mysql.rds_set_external_master ('Aurora_HOSTNAME', 3306,
-> 'repl_user', '<PASSWORD>', 'mysql-bin-changelog.000020', 123280, 0);
Query OK, 0 rows affected (0.31 sec)
mysql> CALL mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.29 sec)
Query OK, 0 rows affected (1.29 sec)
データがレプリケートされることを確認
Master にレコードを追加
Aurora(maser) 側でデータを挿入してみましょう。
mysql> insert into characters(name) values('Immortan Joe');
Slave(Replica) で追加レコードを確認
MySQL(slave/Replica) 側でデータを確認してみましょう。
mysql> select * from characters;
+----+-------------------+
| id | name |
+----+-------------------+
| 1 | Max Rockatansky |
| 2 | Imperator Furiosa |
| 3 | Nux |
| 4 | Immortan Joe |
+----+-------------------+
4 rows in set (0.18 sec)
mysql> call mysql.rds_skip_repl_error();
+---------------------------------------------------------+
| Message |
+---------------------------------------------------------+
| Slave is running normally. No errors detected to skip. |
+---------------------------------------------------------+
1 row in set (0.18 sec)
Query OK, 0 rows affected (0.18 sec)
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: Aurora_HOSTNAME
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
...
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.20 sec)
追加レコードがレプリケートされていることが確認出来ました。
まとめ
今回は Aurora に binlog を出力させて Amazon RDS にレプリケーションしてみました。
一旦 Aurora のデータを binlog に出してしまえば、この binlog インターフェースを通してAurora のいろいろな活用が思い浮かびますね。
